This adds support for cleaning up unused services within an environment.

As Lagoon has typically not cleaned up in the past, this is a potentially dangerous operation in some cases. A user may be unaware that they may still be using or have an old service in their environment, and their application may still be using it.

There isn't any way to actually confirm if a service is still in used by an application during a build, so the action will be to warn and let the user decide on what action to take.

Maybe in the future removals will happen automatically and it will produce a warning still, but no choice in action.

Currently, this can detect and clean up any services, or dangling resources that a service created. In this case a typical service comprises of Kubernetes resources of the types Deployment, and then depending on the service, a Service and/or a PersistentVolumeClaim. A service can also be one of the DBaaS types.

Once the build has detected these, it will output the resources that would be removed and instruct what to do to have them removed. The user can verify the changes and make the decision to remove them in a future build, but also makes it clear that they need to verify that the resources are not used anymore before they are removed.

A new function that will save the service states into a lagoon-services configmap which can be used by the remote-controller to send environment state back to the API for visibility.

To properly support all the changes in this in the API and other systems, the following are required, and the references to pr-99 are added in code to identify where the changes will need to be made in the future to use machinery.

• feat: add more container data and volume data for environments machinery#99
• changes to remote-controller to source new configmap with services information
• changes to api to store additional data for services